Web-based structure access

ABSTRACT

A first user associated with a structure (e.g., a home, a building, etc.) may authorize a second user to access the structure when the first user is not present. The second user may request to access the structure via a text message that includes an access code that was previously provided. The second user may be verified/authenticated based on the telephone number in which the text message was received, the access code, and/or an access schedule that indicates when the second user is authorized to access the structure. The second user may send a second text message indicating a desire to lock/unlock a structure entrance (e.g., a door) to the structure that contains a smart lock. Upon receiving the second text message, a service provider sends an instruction to the smart lock, causing the structure entrance to become locked/unlocked, and allowing the second user to access or secure the structure.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims priority to,co-pending, commonly-owned U.S. patent application Ser. No. 16/188,254,entitled “WEB-BASED STRUCTURE ACCESS”, filed on Nov. 12, 2018, which isa continuation of, and claims priority to commonly-owned U.S. patentapplication Ser. No. 15/628,120, entitled “TEXT-BASED STRUCTURE ACCESS”,filed on Jun. 20, 2017, both of which are incorporated by reference intheir entirety.

BACKGROUND

Users may gain access to a structure (e.g., a residence, a workplace,etc.) in various manners, such as by unlocking a lock with a key,entering a known code using an electronic keypad, or unlocking a smartlock using an electronic device (e.g., a mobile telephone). In the smartlock context, a user typically needs to download an application tohis/her mobile device and then use that application to lock/unlock thesmart lock. However, a user may be unable to lock/unlock a smart lock indifferent scenarios. For instance, the user would be unable tolock/unlock the smart lock if the mobile device of the user is notcapable of downloading/storing applications. Moreover, provided that thesmart lock application did in fact reside on the mobile device, the userwould be unable to access the application due to a poor cellularsignal/connection or Wi-Fi connection (or a lack thereof). This wouldresult in the user being unable to access and/or secure the structure.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanyingfigures. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Theuse of the same reference numbers in different figures indicates similaror identical components or features.

FIG. 1 illustrates an example system for locking/unlocking a smart lockusing a text-based and/or a web-based authentication protocol.

FIG. 2 illustrates an example diagram for generating a guest profile andan access code to be used to facilitate accessing or securing astructure by an authorized user.

FIG. 3 illustrates an example diagram for a text-based process/protocolto facilitate accessing or securing a structure by an authorized uservia a structure entrance having a smart lock.

FIG. 4 illustrates an example diagram for a web-based process/protocolto facilitate accessing or securing a structure by an authorized uservia a structure entrance having a smart lock.

FIG. 5 is a flow diagram illustrating an example process of generating aguest profile and an access code to be used to facilitate accessing orsecuring a structure by an authorized user.

FIG. 6 is a flow diagram illustrating an example process of facilitatingaccessing or securing a structure by an authorized user using atext-based protocol.

FIG. 7 is a flow diagram illustrating an example process of facilitatingaccessing or securing a structure by an authorized user using aweb-based protocol.

DETAILED DESCRIPTION

Described herein are systems and/or processes for facilitating accessingand/or securing a structure by an authorized user via a structureentrance having a smart lock using a text-based and/or a web-basedauthentication protocol. A lock may be locked/unlocked exclusively usinghardware or mechanical components, such as a physical lock and aphysical key that is used to lock/unlock the lock. However, advances intechnology allow doors, windows, etc., to be locked/unlocked digitally,such as by using a code (e.g., a combination of letters, numbers,symbols, etc.) that is entered via an electronic keypad. In addition,existing smart locks allow a user to lock/unlock the smart lock usingtheir electronic device (e.g., a mobile telephone, a tablet computingdevice, etc.). The user may download an application associated with thesmart lock to his/her electronic device, and then use that applicationto lock/unlock the smart lock. However, scenarios exist in which theuser would be unable to lock/unlock the smart lock using theapplication, thereby preventing the user from accessing (e.g. unlockingthe smart lock) or securing (e.g., locking the smart lock) a structure,such as a residence (e.g., a house, an apartment, a condominium, etc.),a workplace, a vehicle, a boat, and so on.

For instance, provided that a door to a house contains a smart lock, andthat a user desires to lock/unlock the smart lock in order to accessand/or secure the house. Although the user may not live at the house,the user (e.g., a guest, a family member, a friend, a servicetechnician, etc.) may be authorized to gain access to the house by theowner/resident. If the user does not possess a smart phone that iscapable of downloading and storing the application needed to lock/unlockthe smart lock, the user would be unable to access the house, or wouldpossibly be unable to secure the house if the house were unlocked.Moreover, even if the user possesses a mobile telephone that is capableof downloading an application that is used to lock/unlock the smartlock, a limited cellular connection and/or a limited Wi-Fi connection(or a lack of a connection) may prevent the user from accessing theapplication. Unless the owner locked/unlocked the smart lock for theuser, the user would be unable to access and/or secure the house.

As a result, the systems and/or processes described therein may allow anowner associated with a structure (e.g., a residence, a workplace, etc.)to designate users/guests that are authorized to gain access to thestructure using a smart lock. For a particular user/guest, the owner mayprovide to a service provider various types of user information, whichmay include an identity of the user/guest, a telephone number of theuser/guest, and/or times/days in which the user/guest is authorized toaccess the structure. Upon receiving such information, the serviceprovider may generate a guest/user profile for the user/guest and anaccess code that is to be used by the user/guest in order to access thestructure. The service provider may provide the access code to theuser/guest, such as via a text message, an e-mail message, etc.

Provided that the user/guest desires to access the structure byunlocking the door having the smart lock, a text-based authenticationprotocol may be used. In particular, the user/guest may send, to theservice provider via his/her mobile device, a text message that includesthe previously provided access code. The service provider may perform atwo-factor authentication to ensure that the user/guest is authorized toaccess the structure at the time the access request is sent. Forinstance, the service provider may verify that the telephone number fromwhich the text message is received matches the telephone numberpreviously provided by the owner, and that the access code includedwithin the text message matches the access code previously generated andprovided by the service provider. If the telephone number or the accesscode do not match, then access to the structure will be denied. However,if the telephone number and the access code are verified, the serviceprovider may confirm whether the time in which the text message wasreceived is during a time in which the owner authorized access to thestructure by the user/guest. If the user/guest is not authorized toaccess the structure at that time, the service provider may deny accessto the user/guest. However, if the user/guest is authorized to accessthe structure at that time, the service provider may send an additionaltext to the user/guest inquiring whether the user/guest would like toaccess (unlock the door) or secure (lock the door) the structure (e.g.,text “1” to unlock, text “2” to lock). Provided that the user/guestsends a text indicating a desire to lock or unlock the smart lock, theservice provider may send an access instruction to the smart lock,thereby causing the door having the smart lock to be locked/unlocked. Asa result, the user/guest may access the structure via the door, window,etc., where the smart lock is located. A similar process may beperformed when the user/guest desires to lock the smart lock and securethe structure.

In other embodiments, the service provider may facilitatinglocking/unlocking of the smart lock using a web-based authenticationprotocol. When sending the access code to the user/guest, the serviceprovider may also send a link or URL to a website that is to be used tofacilitate locking/unlocking the smart lock. When the user/guest desiresto access the structure via the smart lock, the user may select (e.g.,“click on”) the link/URL, which causes a website to be presented on adisplay of the mobile device of the user/guest. Via the website, theuser/guest may input his/her access code. The service provider mayverify whether the access code entered via the website matches thepreviously provided access code. If so, the service provider may performfurther authentication to verify that the mobile device of theuser/guest is in proximity to the smart lock of the structure. Theservice provider may determine a current geographic location of themobile device (e.g., via GPS data, etc.) and verify that the currentgeographic location of the mobile device is within a threshold distance(e.g., 5 feet, 10 feet, etc.) from a known geographic location of thesmart lock/structure. If not, the service provider may deny access tothe structure. However, if the proximity of the mobile device isverified, the service provider may confirm that the user/guest has beenauthorized by the owner to access the structure at that time. Providedthat the user/guest is authenticated and that the user/guest isauthorized to access the structure, the service provider may cause thewebsite to inquire whether the user/guest would like to lock/unlock thesmart lock (e.g., press/select “lock” or “unlock”). Upon receiving aselection from the user/guest via the website, the service provider maysend an access instruction to the smart lock, thereby causing the smartlock to be locked/unlocked. The user/guest may then be allowed to accessor secure the structure.

In some embodiments, regardless of whether a text-based or a web-basedauthentication protocol is used, the service provider may send anotification to the owner indicating that the smart lock has been, orwill be, locked/unlocked, or indicating that an authorized or anunauthorized individual attempted to gain access to the structure. Atany time prior to access, during access, or subsequent to access, theowner may revoke access rights to a user/guest.

FIG. 1 illustrates an example system 100 for facilitating the accessingor securing of a structure by an authorized user, such as bylocking/unlocking a structure entrance having a smart lock. As shown inFIG. 1, the system 100 may include a service provider 102, a contentserver 104 associated with the service provider 102, an owner 106, oneor more owner devices 108 associated with the owner 106, one or moreguests 110, and one or more guest devices 112 associated with theguest(s) 110. The system 100 may also include a structure 116 associatedwith the owner 106, where the structure 116 may include at least onestructure entrance 118 and a corresponding lock 120. The contentserver(s) 104, the owner device(s) 108, the guest device(s) 112, and/orthe lock 120 may communicate via one or more networks 114. As shownherein, the content server(s) 104 may include one or more processors122, computer-readable media 124 (abbreviated as “CRM” in FIG. 1), andone or more modules 126.

For the purpose of this discussion, the service provider 102 may be anyentity, server(s), platform, etc., that offers, to customers, servicesrelating to the security of structures 116, such as residences,workplaces, etc. That is, the service provider 102 may be a home secureaccess control system/service that allows customers to control thesecurity/access of their home(s), particularly when the customer is notpresent at the home. Provided that the structure 116 includes at leastone lock 120, such as a smart lock 120, associated with a structureentrance 118 (e.g., a door, window, etc.), the service provider 102 mayfacilitating the locking/unlocking of lock 120 by the owner 106 or otherindividuals that are authorized by the owner 106 to access the structure116, where such authorized individuals are referred to herein as guests110. The content server(s) 104 associated with the service provider 102may include one or more servers, cloud-based resources, etc., thatperform one or more authentication protocols that allow authorized usersto unlock the structure entrance 118 using the lock 120, therebyproviding access to the structure 116. The authentication protocol(s)may also allow users to lock the structure entrance 118 using the lock120, thereby securing the structure 116, or at least securing thestructure entrance 118 that includes the lock 120. As a result ofverifying/authenticating a user, and verifying that the user isauthorized to access the structure 116 at a particular time, the serviceprovider 102 may cause the lock 120 to lock/unlock the structureentrance 118.

The owner 106 may be any individual or entity that is associated with astructure 116 and that is authorized to grant access to the structure116 to other individuals/entities. For instance, the owner 106 may havean account/profile with the service provider 102, and may authorize theservice provider 102 to lock/unlock a lock 120 of a structure entrance118 of the structure 116 for other individuals/entities. Via the serviceprovider 102, the owner 106 may grant access to otherindividuals/entities even when the owner 106 is not currently located atthe structure 116. For instance, provided that the structure 116 is ahouse, apartment, condominium, etc., the owner 106 may be an individualthat owns or resides at the structure 116. If the structure 116 is aworkplace, the owner 106 may be an owner or employee of acompany/employer that performs business operations (e.g., offersgoods/services for sale) at the structure 116. The service provider 102may serve as a remote system that allows individuals/entities other thanthe owner 106 to access the structure 116 when he/she is not present.

The guest(s) 110 may be any individual or entity in which the owner 106has previously granted authorization to access the structure 116. Forinstance, the guest(s) 110 may include family members (e.g., a spouse, asignificant other, children, grandparents, etc.), roommates, friends,houseguests, neighbors, co-workers, etc. of the owner 106. The guests110 may also include any individual or entity that performs servicesassociated with the structure 116, such as a nanny that cares forchildren of the owner 106, a housekeeper/housekeeping service thatcleans the structure 116, a pet sitter/walker that cares for and/orwalks a pet of the owner 106, and/or a contractor/service technicianthat performs services at the structure 116 (e.g., appliancemaintenance/repair, cable/internet installation/repair, a security alarmservice, etc.). That is, the guest(s) 110 may be any individual/entityin which the owner 106 would like to grant access to the structure 116at a time at which the owner 106 is located elsewhere. For the purposesof this discussion, the owner 106 may also be referred to herein as“primary user” or “first user,” and the guest(s) 110 may be referred toherein as “secondary user(s)” or “second user(s).”

The owner 106 and the guest(s) 110 may each be associated with one ormore owner devices 108 and guest devices 112, respectively. The ownerdevice(s) 108 may also be referred to herein as a “primary user device”or a “first user device,” and the guest device(s) 112 may be referred toherein as a “secondary user device(s)” or a “second user device(s),” orthe owner devices 108 and the guest devices 112 may be referred to as“user devices.” For the purposes of this discussion, the owner device(s)108 and the guest device(s) 112 may correspond to any electronic deviceincluding, but not limited to, mobile telephones, tablet computingdevices, laptop computers, desktop computers, electronic book (eBook)reader devices, gaming consoles, and so on.

The network(s) 114 may facilitate communications and/or interactionsbetween the content server(s) 104 of the service provider 102, the ownerdevice(s) 108, the guest device(s) 112, and/or the lock 120. Thenetwork(s) 114 may facilitate such communications/interactions via anytype of network, such as a public wide-area-network (WAN) (e.g., theInternet), which may utilize various different technologies includingwired and wireless technologies. Moreover, the content servers 104 maycontain any number of servers that are possibly arranged as a serverfarm. Other server architectures may also be used to implement thecontent servers 104.

As stated above, the structure 116 may be any building associated withthe owner 106, including any building that the owner 106 would like togrant access to one or more guests 110. For instance, the structure 116may be a residence, such as a house, a trailer, an apartment, acondominium, etc., or any other building (e.g., a shed, garage, etc.).The structure 116 may also be a workplace (e.g., a commercial building,or a suite within a building), a boat, a vehicle (e.g., a car, amotorhome, etc.), or any other item that the owner 106 authorizes guests110 to access. The structure 116 may include one or more structureentrances 118 that serve as a mechanism for individuals to enter or exitthe structure 116. For instance, a structure entrance 118 may include adoor (e.g., a front/side/back door, a garage door, a car door, etc.) ora window. The structure entrance 118 may include one or more locks 120that serve to secure the structure entrance 118. The lock 120 may beaffixed to the structure entrance 118 (e.g., attached to or insertedinto a door), or be in close proximity to the structure entrance 118.Although the lock 120 may be locked/unlocked using a physical key or viaa code entered using an electronic keypad, for the purposes of thisdiscussion, the lock 120 may be referred to herein as a smart lock 120.

A smart lock 120 may correspond to an electromechanical lock 120 that isdesigned to perform locking and/or unlocking operations on a structureentrance 118 (e.g., a door) when the smart lock 120 receivesinstructions from an authorized device using a wireless protocol and/ora cryptographic/virtual key. Like traditional locks, a smart lock 120includes a lock and a key. However, unlike a physical key, the key maybe a specialized virtual key (e.g., a key fob) that is configured towireless perform an authentication protocol to automatically lock/unlockthe structure entrance 118. The virtual key may be sent to the smartlock 120 by the content server(s) 104, the owner device(s) 108, and/orthe guest device(s) 112 over one or more messaging protocols and/ornetworks, such as e-mail, Short Message Service (SMS), Bluetoothwireless technology (e.g., Bluetooth low energy (BLE)), Secure SocketsLayer (SSL), Wi-Fi, near-field communication (NFC), a cellular network(e.g., 3G, 4G, LTE, etc.), Zigbee, etc. Once the virtual key is receivedby the smart lock 120, hardware and/or software within the smart lock120 cause the structure entrance 118 to be unlocked/locked. Certainsmart locks 120 communicate with the content server(s) 104, the ownerdevice(s) 108, and/or the guest device(s) 112 using a wireless network(Wi-Fi) maintained within the structure 116. However, in otherembodiments, the smart lock 120 may include built-in Wi-Fi.

The smart lock 120 may have various components that allow for thelocking/unlocking of the structure entrance 118. For instance, the smartlock 120 may include hardware and mechanical components similar to astandard lock. Such hardware/mechanical components may be made of metal,such as steel and/or tamper-proof alloys. The smart lock 120 may alsohave an electrical/communication component that receives instructionsfrom the content server(s) 104 and causes the structure entrance 118 tolock/unlock. The smart lock 120 may further include a powerassembly/unit, which may include one or more batteries and/or livecurrent received via one or more electrical wires connected to thestructure 116, and which may supply power/electricity to variouscomponents of the smart lock 120. Also included in the smart lock 120may be a motor. When an access signal is received from the contentserver(s) 104, the motor may activate one or more pins,cylinders/tumblers, and/or slotted rotating discs, which may cause thebolt of the smart lock 120 to draw back from, or move forward into, thecavity associated with the strike plate. Movement of the bolt may causethe structure entrance 118 to lock/unlock.

In some embodiments, the content server(s) 104, the owner device(s) 108,the guest device(s) 112, and/or the lock 120 may include one or moreprocessors 122, computer-readable media 124, which is indicated in FIG.1 as “CRM”, and one or more modules 126. The processor(s) 122 mayexecute the one or more modules 126 and/or processes to cause thecontent server(s) 104, the owner device(s) 108, the guest device(s) 112,and/or the lock 120 to perform a variety of functions, as set forthabove and explained in further detail in the following disclosure. Insome embodiments, the processor(s) 122 may include a central processingunit (CPU), a graphics processing unit (GPU), both CPU and GPU, or otherprocessing units or components known in the art. Additionally, each ofthe processor(s) 122 may possess its own local memory, which also maystore program modules, program data, and/or one or more operatingsystems.

The computer-readable media 124 may include volatile memory (such asRAM), non-volatile memory (such as ROM, flash memory, miniature harddrive, memory card, or the like), or some combination thereof. Thecomputer-readable media 124 may be non-transitory computer-readablemedia 124. The computer-readable media 124 may include, or be associatedwith the one or more modules 126 that perform various operationsassociated with the content server(s) 104, the owner device(s) 108,and/or the guest device(s) 112. In some embodiments, the one or moremodules 126 may include or be associated with computer-executableinstructions that are stored by the computer-readable media 124 and thatare executable by the processor(s) 122 to perform such operations. Thecontent server(s) 104, the owner device(s) 108, and/or the guestdevice(s) 112 may also include additional components not listed abovethat may perform any function associated with the content server(s) 104,the owner device(s) 108, and/or the guest device(s) 112.

Provided that an owner 106 would like to grant/authorize access to astructure 116 to one or more guests 110, the owner 106 may send, to thecontent server(s) 104 and via his/her owner device 108, guestinformation 128. The guest information 128 (or user information) may besent via an e-mail message, a text message, a telephone call, anapplication that resides on the owner device 108 and that is associatedwith the service provider 102, a website of the service provider 102,and so on. Based on the guest information 128, the service provider 102may generate and maintain a guest profile 130 for each guest 110 thathas been authorized access to the structure 116 by the owner 106. Theguest profile 130 (or user profile) may store the guest information 128,which may include the identity of the guests 110 in which access to thestructure 116 is to be authorized (i.e., guest IDs 132), one or moretelephone numbers 134 of each of the guests 110, and/or an accessschedule 136 for each of the guests 110. An access schedule 136 for aguest 110 may indicate an extent to which the guest 110 is authorized toaccess the structure 116, which may include times/days (or a combinationthereof) in which the guest 110 is authorized to have access to thestructure 116 (e.g., anytime, every Tuesday from 9-11 am, July 21-26,etc.), and may specify when access to the structure 116 expires. Theservice provider 102 may also generate an access code 138 (or shortcode) for each guest 110, where the access code 138 may be any numberand combination of characters (e.g., letters, numbers, symbols, etc.)that the guest 110 is to subsequently use in order to gain access to thestructure 116. Upon generation, and as shown in FIG. 1, the access code138 for a guest 110 may be provided to that guest 110, such as via atext or SMS message. In some embodiments, the service provider102/content server(s) 104 and/or the owner 106/owner device(s) 108 mayprovide the access code 138 to the guest device(s) 112 of the guest 110.

Provided that a particular guest 110 desires to gain access to thestructure 116 of the owner 106, the guest 110 may arrive at thestructure 116/structure entrance 118 and submit an access request 140.The access request 140 may take the form of a text message orinformation provided via a website and may represent request tolock/unlock the structure entrance 118. Upon receiving the accessrequest 140, the service provider 102 may perform a guest accessauthentication 142 with respect to the guest 110 and the received accessrequest 140. The guest access authentication 142 may be a process thatverifies the identity of the guest 110 based on the guest profile 130for the guest 110, and that verifies that the guest 110 is authorized toaccess the structure 116 at the time the access request 140 is receivedpursuant to the access schedule 136 for that guest 110. The guest accessauthorization 142 may be text-based 144 and/or web-based 146. As will bedescribed in additional detail herein, with respect to a text-based 144guest access authentication 142, the access request 140 may constitute atext message sent by the guest device 112 of the guest 110 to theservice provider 102, where the text message includes the access code138 of the guest 110. The service provider 102 may authenticate theguest 110 based on the telephone number 134 in which the text messagewas sent, the access code 138 included in the text message, and theaccess schedule 136 of the guest 110. On the other hand, in a web-based146 guest access authentication 142, the access request 140 maycorrespond to the guest 110 submitting the access code 138 via a websitethat is associated with a link/URL that was previously provided by theservice provider 102. In the web-based 146 scenario, the guest 110 maybe authenticated based on the access code 138 and a proximity betweenthe current location of the guest device 112 that was used to submit theaccess code 138 and a known location of the structure entrance 118/lock120.

Assuming that the guest access authentication 142 process verifiesand/or authenticates the guest 110, the service provider 102 mayinquire, via a text message (in the text-based 144 example) or thewebsite (in the web-based 146 example), whether the guest 110 would liketo lock or unlock the structure entrance 118. The guest 110 may providea response via a text message or the website and, based on the response(e.g., lock or unlock the structure entrance 118), the service provider102 may send one or more access instructions 148 to the lock 120. Theaccess instruction(s) 148 may instruct the lock 120 to either lock orunlock the structure entrance 118, which may allow the guest 110 toaccess the structure 116 via the structure entrance 118 or secure thestructure 116 by locking the structure entrance 118. Instead of beingsent directly to the lock 120, the access instructions 148 may becommunicated or transmitted to a separate device that thencommunicates/transmits instructions (e.g., the access instructions 148or different/modified instructions) to the lock 120. This device may bea server or a hub that is located at the structure 116 or that islocated remotely from the structure 116. In some embodiments, andpossibly based on a preference/setting set forth by the owner 106,either prior to or after the access instructions 148 are sent, theservice provider 102 may send an access notification 150 to the owner106, where the access notification 150 may indicate that the guest 110is attempting to access, or has accessed, the structure 116.

In certain embodiments, the system 100 may also include one or morecameras (e.g., still image cameras, video cameras, etc.) that arelocated at or near the structure entrance 118 of the structure 116. Thestructure entrance 118 may be within a field of view of the camera(s)such that images and/or video captured by the camera(s) may depict theguest 110 that is attempting to access or secure the structure 116. Insome embodiments, the camera(s) may capture images/video continuously ormay capture images/video in response to a motion sensor detectingmovement within its field of view. However, in other embodiments, thecamera(s) may begin capturing images/video when the access request 140is submitted by the guest 110, when the access instructions 148 are sentby the content server(s) 104, or when the structure entrance 118 isunlocked/locked. If the camera(s) capture video data, once the camera(s)begin capturing video, the camera(s) may capture video for a particularperiod of time (e.g., 30 seconds). As a result, the images/video maydepict the guest 110 that is entering/exiting the structure 116 via thestructure entrance 118. The images/video may be maintained in the CRM124 of the content server(s) 104, and may be transmitted to the owner106 (e.g., via a text message, an e-mail message, a mobile application,etc.). That way, the owner 106 may view individuals (e.g., guests 110)that are accessing and/or securing, or are attempting to access/secure,the structure 116.

FIG. 2 illustrates an example diagram 200 for generating a guest profileand an access code to be used to lock/unlock a structure entrance of astructure having a smart lock. As illustrated, the diagram 200 includesthe content server(s) 104, an owner device 108 associated with an owner106, and a guest device 112 associated with a guest 110. For thepurposes of FIG. 2, the owner 106 may be associated with a structure 116(e.g., a residence, a workplace, etc.) and the guest 110 may be anindividual/entity that the owner 106 would like to grant/authorizeaccess to the structure 116. For instance, the guest 110 may be a familymember, friend, neighbor, etc., of the owner 106 or an individual/entitythat is to perform services in association with the structure 116 (e.g.,a contractor, a service technician, a nanny, a pet caregiver, etc.).

In order to authorize the guest 110 to have access to the structure 116,the owner 106, via the owner device 108, may send guest information 128to the service provider 102. The guest information 128 may be providedvia a text message, an e-mail message, an application that resides onthe owner device 108 and that is associated with the service provider102, a website associated with the service provider 102, and so on.Moreover, the guest information 128 may include various types ofinformation about the guest 110. For instance, the guest information 128may possibly include an identity (i.e., guest ID 132) of the guest 110(e.g., a name, an identifier, etc.), a telephone number 134 of a mobiletelephone of the guest 110, and any other information associated withthe guest 110.

The guest information 128 may also include information regarding whenthe guest 110 is authorized to have access to the structure 116. Forinstance, the owner 106 may specify particular time(s) (e.g., 9-11 am)and/or days (e.g., Tuesdays) in which access is authorized, a durationof the authorized access (e.g., two hours, all day, two weeks, etc.),whether the authorized access is recurring (e.g., daily, weekly,monthly, etc.), whether the authorized access expires (e.g., two weeks,two months, etc.), and so on. The extent to which the guest 110 isauthorized access to the structure 116 may be referred to herein as theaccess schedule 136, and the access schedule 136 may be generated by theowner 106 (i.e., access schedule generation 202) and provided to theservice provider 102. In other embodiments, the owner 106 may providesuch information to the service provider 102 and the service provider102 may then generate the access schedule 136 for the guest 110 based onthe access information provided by the owner 106.

As discussed above, the access schedule 136 for a particular guest 110may indicate an extent to which access to the structure 116 isauthorized. In particular, the access schedule 136 may specify times atwhich the guest 110 is authorized to access the structure 116 (via thestructure entrance 118 having the lock 120). For example, the guest 110may always have access, regardless of the time of day or the day of theweek. Access to the structure 116 by the guest 110 may also be for aparticular time (e.g., 10 am), time period (e.g. 9-11 am), or day (e.g.,Tuesdays), or a combination thereof (e.g., Tuesdays from 9-11 am).Access during these times/days may also be recurring (e.g., everyTuesday between 9-11 am, monthly, etc.). Access to the structure 116 bythe guest 110 may also be a one-time access, and the guest 110 may nothave access to the structure 116 after that time unless the owner 106subsequently authorizes further access by the guest 110.

The access schedule 136 may also indicate the length of time in whichaccess is authorized. Access to the structure 116 may be authorized foran indefinite period of time (no end time/date), or for a particularduration of time. For instance, the guest 110 may have access to thestructure 116 until a certain date (e.g., access until July 24^(th)) orfor a certain time period (June 1^(st) to July 31^(st)). In someembodiments, if the owner 106 does not specify conditions in which theguest 110 is authorized to access the structure 116, the serviceprovider 102 may infer that the guest 110 is authorized to access thestructure 116 at any time for an indefinite amount of time (no enddate/time).

Upon receiving the guest information 128 and the access schedule 136from the owner 106 (or after generating the access schedule 136 based oninformation provided by the owner 106), the service provider 102 maygenerate a guest profile 130 for the guest 110 (i.e., guest profilegeneration 204). The guest profiles 130 may be maintained by the contentserver(s) 104 and then accessed when a guest 110 requests to access astructure 116. In addition to generating the guest profile 130 for aguest 110, the service provider 102 may generate an access code 138 forthe guest 110 (i.e., access code generation 206). The access code 138for a particular guest 110 may be any number or combination of letters,numbers, symbols, etc. and may be maintained in the guest profile 130 ofthe guest 110. In some embodiments, the access code 138 may be a shortcode or short number (collectively referred to herein as “short code(s)”or “dedicated short code(s)”), which may correspond to short digitsequences (e.g., a six-digit alphanumeric code) that are typicallyshorter than telephone numbers, and a short code may serve to replace atelephone number. Short codes may be used to address messages in theMultimedia Messaging system (MMS) and SMS of mobile network operators.Regardless of the type of access code 138, each guest 110 may beassigned a different and/or unique access code 138.

The service provider 102 may send the access code 138 associated withthe guest 110 to a corresponding guest device 112, such as via a textmessage, an e-mail message, a mobile application, a website, and so on.Provided that the access code 138 is sent via a text message, the textmessage sent by the service provider 102 may include the access code138, and the text message may be sent via a dedicated short codeassociated with the service provider 102. For the purposes of thisdiscussion, each guest 110 may send text messages to the same short codeof the service provider 102 for the purpose of submitting an accessrequest 140, and reply text messages from the service provider 102 willbe received from this short code. The guest 110 may maintain his/heraccess code 138 when subsequently requesting to access the structure 116associated with the owner 106. In some embodiments, the text messagesent by the service provider 102 may indicate that the owner 106 hasauthorized the guest 110 to access the structure 116, and that theaccess code 138 will be needed for subsequent access. For instance, thetext message could state, “Jim has granted you access to his home, andaccess code 398567 is needed for access.” In order for the guest 110 tosubsequently access the structure 116 via the structure entrance 118(and cause the structure entrance 118 to be locked/unlocked using thelock 120), the guest 110 may need to provide the previously providedaccess code 138. As discussed in additional detail with respect to FIG.4, for the web-based 146 guest access authentication 142, the textmessage may include both the access code 138 for the guest 110 and alink/URL to a website that will be used to submit an access request 140.

In some embodiments, instead of, or in addition to, the service provider102/content server(s) 104 sending the access code 138 to the guestdevice 112 of the guest 110, the service provider 102/content server(s)104 may transmit the access code 138 assigned to the guest 110 to theowner 106. The owner 106, via his/her owner device 108, may then sendthe access code 138 to the guest device 112 of the guest 110 via a textmessage, an e-mail message, etc. For instance, a text message sent bythe owner 106 to the guest 110 may state, “Hi John, I have granted youaccess to my home, and you can use access code 398567 for access.” Inother embodiments, the service provider 102/content server(s) 104 maysend the access code 138 assigned to the guest 110 to both the owner 106and the guest 110.

FIG. 3 illustrates an example diagram 300 for facilitating access to astructure by a guest based on a text-based authentication protocol. Asdiscussed above with respect to FIG. 2, an owner 106 associated with astructure 116 (e.g., a house) may authorize a guest 110 to access thestructure 116. More particularly, the owner 106 may authorize the guest110 to access the structure 116 via a structure entrance 118 thatincludes a lock 120, such as a smart lock 120. The service provider 102may generate an access code 138 (e.g., a short code) that may be used bythe guest 110 to access the structure 116. Upon the guest 110 submittingan access request 140 to the service provider 102 to access thestructure 116, the service provider 102 may perform a guest accessauthentication 142 protocol to verify/authenticate the guest 110. Theguest access authentication 142 may be text-based 144 or web-based 146.The diagram 300 illustrated in FIG. 3 relates to the text-based 144guest access authentication 142. As shown, the diagram 300 includes thecontent server(s) 104 associated with the service provider 102, an ownerdevice 108 associated with an owner 106, and a guest device 112associated with a guest 110. The owner 106 may be associated with astructure 116 that is to be accessed by the guest 110, withauthorization by the owner 106.

When the guest 110 would like to access the structure 116, such as whenthe guest 110 arrives at the location of the structure (e.g., a house),the guest 110 may submit an access request 140 via his/her guest device112 (e.g., a mobile telephone). In particular, the guest 110 maysubmit/send a text-based access request 302 to the service provider 102,where the text-based access request 302 may be a text message sent to atelephone number or short code associated with the service provider 102.In order to gain access to the structure 116, the guest 110 may include,within the text message, the access code 138 that is associated with theguest 110 and that was previously provided to the guest 110 by theservice provider 102. Since the owner 106 previously identified thetelephone number 134 of the guest 110 in the guest information 128provided to the service provider 102, the guest 110 should send the textmessage from the mobile telephone that is associated with that telephonenumber 134.

Upon receiving the text-based access request 302 from the guest 110, theservice provider 102 may perform a search with respect to the guestprofiles 130 generated by the service provider 102 and maintained in thecontent server(s) 104. In particular, the service provider 102 maysearch the guest profiles 130 using the telephone number 134 in whichthe text message was received and/or the access code 138 that wasincluded in the text message. As a result of the search, the serviceprovider 102 may identify the guest profile 130 associated with theguest 110 that submitted the text-based access request 302. The serviceprovider 102 may then authenticate the guest 110 in order to verify thatthe text-based access request 302 was sent by an individual that isauthorized by the owner 106 to access the structure 116, and to preventallowing unauthorized individuals to access the structure 116. Theservice provider 102 may perform a two-factor authentication withrespect to the text-based access request 302. The service provider 102may perform a telephone number verification 304 to confirm that the textmessage was received from the telephone number 134 included in the guestprofile 130 of the guest 110. That is, the service provider 102 mayconfirm that the text message was received from the telephone number 134of the guest 110 that was previously identified by the owner 106. If thetelephone number 134 associated with the text message does not match thetelephone number 134 included in the guest profile 130 of the guest 110,the service provider 102 may deny access to the structure 116. In thisscenario, the service provider 102 may send a return text message to thetelephone number 134 indicating that access to the structure 116 hasbeen denied.

If the telephone number verification 304 verifies that the text-basedaccess request 302 (i.e., the text message) was received from thetelephone number 134 identified in the guest profile 130 of the guest110, the service provider 102 may perform an access code verification306. The access code verification 306 may verify that the access code138 included in the text message received from the telephone number 134matches the access code 138 included in the guest profile 130 of theguest 110. If so, and provided that the telephone number verification304 confirms that the text message was received by the telephone number134 of the guest 110, the service provider 102 may verify that thetext-based access request 302 was received from a guest 110 that isauthorized to access the structure 116. However, if the access code 138included in the text message is not the same as the access code 138included in the guest profile 130 of the guest 110, then the serviceprovider 102 may deny access to the structure 116. The service provider102 may send a text message to the telephone number 134 that submittedthe text-based access request 302 indicating that access to thestructure 116 has been denied.

Provided that the guest 110 is authorized to access the structure 116,the service provider 102 may perform an access schedule verification308. In various embodiments, the access schedule verification 308 maydetermine whether, at the time the text-based access request 302 wassubmitted/received, the guest 110 is authorized to access the structure116. As discussed herein, the owner 106 may specify times at whichdifferent guests 110 are authorized to access the structure 116. Forinstance, the owner 106 may specify that a guest 110 may access thestructure 116 anytime, on certain days, at certain times, on certaindays at certain times, and so on. The guest profile 130 of the guest 110may include an access schedule 136 that indicates times/days (or acombination thereof) in which access to the structure 116 by the guest110 is authorized. As a result, upon receiving the text-based accessrequest 302, the service provider 102 may verify that the guest 110 isin fact authorized or scheduled to access the structure 116 at thattime. If the guest 110 is not authorized to access the structure 116 atthat time, the service provider 102 may deny access to the structure 116and send a corresponding text message to the guest device 112 of theguest 110.

Provided that the telephone number verification 304, the access codeverification 306, and/or the access schedule verification 308 isconfirmed/verified, the service provider 102 may request what action theguest 110 would like to take/perform. In various embodiments, theservice provider 102 may perform some, all, or none of the foregoingverifications, and some, all, or none of these verifications need to besatisfied in order to authorize access to the guest 110. In someinstances, the guest 110 may request that the structure entrance 118 beunlocked so that the guest 110 is able to access the structure 116. Onthe other hand, if the guest 110 has already access the structure 116and is leaving, the guest 110 may desire to lock the structure entrance118 so that the structure 116 is secure. Accordingly, the processillustrated in FIG. 3 may apply to the unlocking of the structureentrance 118 and access to the structure 116, as well as to the lockingof the structure entrance 118 and securing the structure 116.

To determine which action the guest 110 desires to take, the serviceprovider 102 may send, to the guest device 112, a text-based accessinquiry 310. The text-based access inquiry 310 may be a text messagethat provides options regarding locking/unlocking the structure entrance118. For instance, the text message may instruct the guest 110 to send afirst text message if the guest 110 would like to unlock the structureentrance 118 and access the structure 116 (e.g., “text ‘1’ or ‘unlock’to unlock/access”), or send a second text message if the guest 110 wouldlike to lock the structure entrance 118 and secure the structure 116(e.g., “text ‘2’ or ‘lock’ to lock/secure”). The particular text messagethat is to be sent by the guest 110 to lock/unlock the structureentrance 118 may be static and remain the same (e.g., “1” to unlock, “2”to lock), or may dynamically change over time. To prevent spoofing, theservice provider 102 may send the text message by initiating a newconversation, as opposed to directly replying to the text message sentby the guest 110. However, the text message sent by the service provider102 may appear in the conversation history on the guest device 112 ofthe guest 110.

After sending the text-based access inquiry 310 to the guest device 112of the guest 110, the service provider 102 may determine if the guest110 responds within a threshold amount of time (e.g., 10 seconds, 1minute, 5 minutes, etc.). If the guest 110 does not send a text messageto the service provider 102 within that specified or predeterminedamount of time, access to the structure 116 may be denied and the guest110 may have to repeat the process set forth above in order toaccess/secure the structure 116. The service provider 102 may send atext to the guest device 112 indicating that the text-based accessrequest 302 timed out and that the guest 110 will need to again requestaccess to the structure 116 in order to gain access.

In some embodiments, the service provider 102 may receive, from theguest device 112 of the guest 110, a text-based access response 312. Thetext-based access response 312 may be responsive to the text-basedaccess inquiry 310 and may take the form of a text message from theguest device 112 of the guest 110. Such a text message may indicatewhether the guest 110 desires to access/unlock or secure/lock thestructure 116. For instance, the text message may include a “1” or theterm “unlock” to unlock the structure entrance 118 so that the guest 110may access the structure 116. The text message may instead include a “2”or the term “lock” to lock the structure entrance 118 and thereforesecure the structure 116. Provided that the text-based access response312 is received from the guest device 112 within the threshold amount oftime, the service provider 102 may determine that the guest 110 wouldlike to access or secure the structure 116 and cause the structureentrance 118 to be unlocked or locked, respectively.

In order to cause the structure entrance 118 to be unlocked/locked, theservice provider 102/content server(s) 104 may send one or moreinstructions to a server, device, hub, etc., that transmits furtherinstructions to the smart lock 120 using any type of communicationprotocol/network. The access instructions 148 may also be sent directlyto the smart lock 120 associated with the structure entrance 118 (i.e.,send access instructions to lock 314). Provided that the accessinstructions 148 are transmitted directly to the lock 120, the accessinstructions 148 may be sent to hardware and/or software components ofthe smart lock 120 using any type of communication protocol/network(e.g., Zigbee, Bluetooth, etc.). In some embodiments, the accessinstructions 148 may include one or more digital keys that cause thesmart lock 120 to lock/unlock. The access instructions 148 may cause thesmart lock 120 to lock/unlock the structure entrance 118, therebyallowing the guest 110 to access the structure 116 via the structureentrance 118 or secure the structure entrance 118. As a result, theguest 110 may access/secure the structure 116 via an exchange of one ormore text messages, and without having to use an application residing ona mobile telephone/electronic device.

In some instances, and possibly based on preferences/settings specifiedby the owner 106, the service provider 102 may send one or more accessnotifications 316 to the owner device 108 of the owner 106. An accessnotification 316 may take the form of an e-mail message, a text message,etc., and may notify the owner 106 that an authorized guest 110accessed/secured the structure 116 or that an authorized guest 110attempted to access the structure 116 at a time at which the guest 110did not have authority to access the structure 116. Such an accessnotification 316 may be sent at the time the text-based access request302 is received, during access by the guest 110, or after the guest 110has accessed/secured the structure 116. The access notification 316 mayalso notify the owner 106 that an unauthorized individual attempted toaccess the structure 116, or that an unauthorized individual did in factaccess the structure 116. In various embodiments, an access notification316 may be sent to the owner device 108 of the owner 106 each time thestructure entrance 118 is locked or unlocked using the smart lock 120.

The owner 106 may revoke or modify an authorization to access thestructure 116 with respect to a guest 110 at any time (i.e., guestaccess revocation 318). In some embodiments, the owner 106 may elect torevoke or modify the extent to which a guest 110 is authorized to accessthe structure 116 after an access request 140 is received. For instance,the service provider 102 may receive an access request 140 from a guest110, and then send an access notification 316 to the owner device 108indicating that the guest 110 is attempting to access the structure 116.At that time, the owner 106 may elect to modify/revoke access to thestructure 116 by the guest 110. In response the service provider 102 mayindicate to the guest 110, such as via a text message or via a website,that access to the structure 116 has been denied and/or revoked.

It is contemplated that, after an authorized guest 110 accesses thestructure 116, he/she may forget to lock the structure entrance 118 tosecure the structure 116. That is, the guest 110 may not perform theprocess illustrated in FIG. 3 in order to lock the structure entrance118. In this scenario, the service provider 102 may cause the structureentrance 118 to be locked in order to secure the structure 116. Forinstance, the service provider 102 may send a notification to the ownerdevice 108 of the owner 106 informing the owner 106 that the structureentrance 118 has not been locked/relocked after being unlocked. Inresponse, the owner 106 may send an instruction to the service provider102 requesting that the structure entrance 118 be locked. Alternatively,the owner 106 may cause the structure entrance 118 to be locked using anapplication that resides on the owner device 108 or via a website. Inother embodiments, the service provider 102 and/or the owner 106 maydetermine that the structure entrance 118 is to be locked within athreshold amount of time (e.g., 10 seconds, 30 seconds, 1 minute, 5minutes, etc.) after being unlocked. In this scenario, the structureentrance 118 may be automatically locked without the owner 106 having toprovide any instructions.

As stated elsewhere herein, in order to lock/unlock existing smartlocks, a user would need to access and interact with an application thatis downloaded to, and that resides on, a mobile device, such as asmartphone. Non-smartphone users would be unable to lock/unlock existingsmart locks using their mobile device. If a user does not have aphysical key to lock/unlock the smart lock, or if the user does not knowa code to input into a keypad (if one is even present), the user wouldbe unable to access and/or secure the house, building, etc., associatedwith the smart lock. Accordingly, a technological problem exists withrespect to non-smartphone users accessing/securing a house/building thatincludes a smart lock. The process illustrated in FIG. 3 and describedherein sets forth a technological solution to this technologicalproblem. Since the systems and process described herein allow a user tounlock/lock a door to a house/building that contains a smart lock 120using one or more text messages, a user would not need a smartphone toaccess/secure the house/building. A non-sophisticated mobile device thatdoes not have the ability to connect to the Internet or downloadapplications, but possesses the ability to send/receive text messages,can be used to access/secure a house/building having a smart lock 120.This technological solution applies to a multitude of individuals thatdo not possess a smartphone for a variety of reasons. Such users mayinclude those that cannot, or will not, pay the costs of a smartphone,those that are unwilling or unable to pay the costs for a data planneeded for using a smartphone, those that are unfamiliar oruncomfortable with the always changing technology associated withsmartphones, those that are traveling (possibly abroad) and who do nothave a data plan during such travels, and so on.

FIG. 4 illustrates an example diagram 400 for facilitating access to astructure by a guest based on a web-based authentication protocol. Thisprotocol may correspond to the web-based 146 guest authenticationprotocol 142 illustrated in FIG. 1. As illustrated, the diagram 400 mayinclude the content server(s) 104 associated with the service provider102, an owner device 108 associated with an owner 106, and a guestdevice 112 associated with a guest 110 that desires to access astructure 116 (e.g., a house) associated with the owner 106. Asdiscussed herein, upon generating a guest profile 130 for the guest 110,the service provider 102 may generate an access code 138 for the guest110 and send the access code 138 to the guest device 112 of the guest110 via a text message, an e-mail message, etc. Along with the accesscode 138, the service provider 102 may include a link to, or a URL for,a website that is to be subsequently used by the guest 110 toaccess/secure the structure 116.

In some embodiments, upon the owner 106 authorizing a guest 110 to haveaccess to a structure 116, the service provider 102 may send a textmessage to the guest device 112 of the guest 110. The text message mayindicate that the owner 106 has elected to grant access to the structure116, and that the guest 110 can select the link/URL and enter the accesscode 138 when the guest 110 is schedule to access the structure 116(e.g., “Bob Jones has shared access to his home. When you are scheduledto visit, click on the link and enter your unique identification code[abc123] to gain access”). The guest 110 may also receive a text messagefrom the telephone number of the owner 106, which may state that theowner 106 has authorized access to the structure 116 and to expect atext message with additional information from the service provider 102(e.g., “I just shared access with you. Expect an additional text withfurther information, and your unique identification code is [abc123]”).

When the guest 110 would like to access (or secure) the structure 116 byunlocking/locking a structure entrance 118 of the structure 116, theguest 110 may submit a web-based access request 402 via his/her guestdevice 112. In particular, via his/her guest device 112, the guest 110may select the link/URL that was previously provided by the serviceprovider 102, which may cause a website associated with the serviceprovider 102 to be presented on a display of the guest device 112. Viathe website, the guest 110 may input/enter his/her access code 138 andsubmit the web-based access request 402, such as by actuating aselectable option (e.g., a button) within the website. The serviceprovider 102 may then receive the web-based access request 402, whichincludes the access code 138 of the guest 110.

In order to verify that the web-based access request 402 is from anindividual that is authorized by the owner 106 to access the structure116, the service provider 102 may perform an access code verification404, which may be similar to the access code verification 306 describedabove with respect to FIG. 3. In some embodiments, the link/URL providedto the guests 110 may be unique for each guest 110, such that serviceprovider 102 may determine the identity of the guest 110 when the guest110 submits the web-based access request 402 via the website associatedwith the unique link/URL. In some embodiments, the link/URL may bechanged over time for security purposes. If the link/URL is unique tothe guest 110, the service provider 102 may determine the identity ofthe guest 110 prior to performing the access code verification 404. Inother embodiments, however, the link/URL provided to the guest 110 maybe generic such that the same link/URL is provided to each guest 110. Inthat scenario, the service provider 102 may determine the identity ofthe guest 110 as a result of the access code verification 404, or as aresult of the guest 110 providing login information associated with anaccount/profile of the guest 110 with respect to the service provider102. Regardless of whether the link/URL is generic or unique, via theaccess code verification 404, the service provider 102 may determinewhether the access code 138 submitted via the website is the same as theaccess code 138 included in the guest profile 130 of the guest 110. Ifnot, the service provider 102 may deny access to the structure 116 andindicate, via the website, that the guest 110 is not authorized toaccess the structure 116. Provided that the access code 138 submittedwith the web-based access request 402 matches the access code 138included in the guest profile 130 of the guest 110, the service provider102 may determine that the guest 110 has been authorized by the owner106 to access the structure 116.

To further verify/confirm authorization to access the structure 116, theservice provider 102 may determine, receive, and/or obtain location data406 associated with the guest device 112 of the guest 110. Moreparticularly, the service provider 102 may determine a currentgeographic location of the guest device 112 (e.g., GPS coordinates) thatsubmitted the web-based access request 402. The location data 406 may bedetermined based on an application that resides on the guest device 112and that is associated with the service provider 102, and/or a locationsensor associated with the guest device 112. Although the location ofthe guest device 112 may be determined in any manner, the location maybe determined using GPS technology, triangulation, multilateration ofradio signals between cell towers of the network of the guest device112, and so on. In various embodiments, before obtaining location data406 associated with the guest device 112, the service provider 102 mayrequest, via the website, permission from the guest 110 to accesshis/her location. The guest 110 may select an option to allow theservice provide 102 to access the current location of the guest device112. However, if the guest 110 does not respond or does not grantpermission, access to the structure 116 may be denied.

Upon determining the location data 406, the service provider 102 mayperform a guest device proximity verification 408. That is, the serviceprovider 102 may determine whether the guest device 112 is within apredetermined or threshold distance from the structure 116 and/or thestructure entrance 118 that would be used to access the structure 116.Based on an address of the structure 116 or location data provided bythe smart lock 120 associated with the structure entrance 118, theservice provider 102 may determine a known location of the structure116/structure entrance 118. Such information may also be provided by theowner 106 associated with the structure 116. Via the guest deviceproximity verification 408, the service provider 102 may determinewhether the current location of the guest device 112 is within apredetermined/threshold distance (e.g., 5 feet, 20 feet, etc.) from theknown location of the structure 116/structure entrance 118. Instead of,or in addition to, using GPS to determine the current location of theguest device 112, the service provider 102 may determine the proximityof the guest device 112 to the structure 116/structure entrance 118based on the guest device 112 connecting to a Wi-Fi network associatedwith the structure 116 or the lock 120. In other embodiments, theproximity of the guest device 112 to the structure 116/structureentrance 118 may be determined based on the guest device 112 connectingto the lock 120 or a different device associated with the structure 116via a Bluetooth connection.

As described above, the guest device proximity verification 408 may beperformed based on the current location of the guest device 110.However, the service provider 102 may perform the guest device proximityverification 408 without receiving or obtaining location data (e.g., GPSdata) associated with the guest device 112. In particular, the serviceprovider 102 may request that the guest 110 provide information that canbe used to verify that the guest 110 is currently located at thestructure 116 and/or structure entrance 118. For instance, the serviceprovider 102 may request, or the guest 110 may provide, informationregarding a shape, color, design, type, etc., of the structure entrance118 (e.g., “what color is the door?”, “how many windows does the doorhave?”, etc.), the number of windows in proximity to the structureentrance 118, or any other information that indicates that the guest 110is currently located at or near the structure entrance 118. The questionmay be presented, and/or the information may be provided, via one ormore text messages or via the website associated with the uniqueURL/link that was previously provided to the guest 110.

Upon determining that the current location of the guest device 112 iswithin a predetermined/threshold distance from the geographic locationof the structure 116/structure entrance 118, the service provider 102may determine that the guest device proximity verification 408 has beensatisfied. As a result, the service provider 102 may authenticate theguest 110 by confirming the identity of the guest 110 based on theaccess code 138 and by confirming that the guest 110 is located at thestructure 116 based on the current location of the guest device 112.Similar to the process illustrated in FIG. 3, the service provider 102may perform an access schedule verification 410 to confirm that theguest 110 is authorized to access the structure 116 at that time, suchas at the time the web-based access request 402 is submitted by theguest 110 and received by the service provider 102. The access scheduleverification 410 may be based on the access schedule 136 included withinthe guest profile 130 of the guest 110. If the access schedule 136 ofthe guest 110 indicates that the guest 110 is not authorized by theowner 106 to access the structure 116 at that time, the guest 110 willreceive, via the website, a notification indicating that access to thestructure 116 has been denied.

Provided that the guest 110 is authorized to access the structure 116 atthe time the web-based access request 402 is submitted, in order todetermine which action the guest 110 desires to take, the serviceprovider 102 may send, to the guest device 112, a web-based accessinquiry 412. That is, via the website, the service provider 102 maypresent a first selectable option to unlock the structure entrance 118(e.g., access the structure 116) and a second selectable option to lockthe structure entrance 118 (e.g., secure the structure 116). Forinstance, the website may present a “lock” button and an “unlock”button. The guest 110 may then have the option of selecting whetherhe/she would like to lock or unlock the structure entrance 118 of thestructure 116. The guest 110 selecting an option to lock or unlock thestructure entrance 118 via the website may be referred to herein as aweb-based access response 414.

After presenting the web-based access inquiry 412 to the guest device112 via the website, the service provider 102 may determine if the guest110 responds within a threshold amount of time (e.g., 10 seconds, 1minute, 5 minutes, etc.). If the guest 110 does not select one of theselectable options to lock/unlock the structure entrance 118 within thatspecified or predetermined amount of time, access to the structure 116may be denied and the guest 110 may have to repeat the process set forthabove in order to access the structure 116. The service provider 102 maypresent, via the website, a notification indicating that the web-basedaccess request 402 timed out and that the guest 110 will need to againrequest access to the structure 116 in order to gain access.

Provided that the web-based access response 414 is received from theguest device 112 via the website within the threshold amount of time,the service provider 102 may determine that the guest 110 would like toaccess or secure the structure 116 and cause the structure entrance 118to be unlocked or locked, respectively. In order to cause the structureentrance 118 to be unlocked/locked, the service provider 102/contentserver(s) 104 may send one or more instructions to the smart lock 120associated with the structure entrance 118 (i.e., send accessinstructions to lock 416). The access instructions 148 may be sent tohardware and/or software components of the smart lock 120 using any typeof communication protocol/network (e.g., Zigbee, Bluetooth, etc.). Insome embodiments, the access instructions 148 may include one or moredigital keys that cause the smart lock 120 to lock/unlock. The accessinstructions 148 may cause the smart lock 120 to lock/unlock thestructure entrance 118, thereby allowing the guest 110 to access thestructure 116 via the structure entrance 118 or secure the structureentrance 118. As a result, the guest 110 may access/secure the structure116 via a website associated with the service provider 102, and withouthaving to download an application to a mobile telephone/electronicdevice.

As described in additional detail with respect to FIG. 3, the serviceprovider 102 may send, to the owner device 108, one or more accessnotifications 418 indicating that an individual has accessed, orattempted to access, the structure 116. The owner 106 may also elect tomodify or revoke access by a guest 110 to the structure 116 at his/herdiscretion.

For the purposes of this discussion, although the guest device 112 maysend and receive information via text messages, a display, a website,etc., information may be input and output via the guest device 112 in anaudible manner. For instance, one or more microphones of the guestdevice 112 may capture one or more voice commands audibly uttered by aguest 110 associated with the guest device 112. The audible commands maycorrespond to an access request 140, inputting an access code 138,specifying a current location of the guest device 112, indicating arequest to unlock or lock a structure entrance 118, and so on. Theaudible commands may be referred to as audio data. The microphone(s) ofthe guest device 112 may generate one or more audio signals thatrepresent the audio data. The guest device 112, the service provider102, and/or the content server(s) 104 may process/analyze the audiosignal(s) using one or more automated speech recognition (ASR) and/ornatural language processing (NLP) techniques to determine one or morewords audibly uttered by the guest 110, and perform operations inresponse thereto. In addition, information provided by the serviceprovider 102/content server(s) 104 to the guest device 112 (e.g., anoption for the guest 110 to lock/unlock the structure entrance 118) maybe audibly output by one or more speakers of the guest device 112.

The process illustrated in FIG. 4 and described herein improves thefunctioning of a mobile device of a user that is attempting toaccess/secure a house/building that contains a smart lock. For instance,since the smart lock 120 may be locked/unlocked using a web-basedprocess where the service provider 102 and a user interact via awebsite, a mobile application is not needed. As a result, users need notdownload a mobile application to his/her mobile device, and the mobiledevice need not store such a mobile application. Since a mobileapplication dedicated to the smart lock 120 does not need to be storedon the mobile device, memory on the mobile device can be preserved andcan be used to store other data, applications, etc., that are used toperform operations by the mobile device. Increased memory availabilitymay also allow the mobile device to function more efficiently, and mayreduce the load experienced by processors 122 of the mobile device.

The processes illustrated in FIGS. 3 and 4 and described herein alsoreduce the risk/likelihood of unauthorized access of the structure 116using electronic devices. The multi-step authentication protocoldescribed with respect to FIG. 3 (e.g., telephone number verification304, access code verification 306, access schedule verification 308,etc.) reduces the likelihood that an unauthorized individual/entitywould be able to access the structure 116. For instance, in order for anunauthorized individual/entity to access the structure 116 in amalicious manner, the individual/entity would have to know the addressof the structure 116, know the access schedule 136 of a particular guest110 (e.g., times/days in which the guest 110 is authorized to access thestructure 116), know the unique access code 138 of the guest 110, andspoof the telephone number 134 of the guest 110. Similarly, themulti-step authentication protocol described with respect to FIG. 4(e.g., access code verification 404, guest device proximity verification408, access schedule verification 410, etc.) also reduces the likelihoodthat an unauthorized individual/entity would be able to access thestructure 116. For instance, in order for an unauthorizedindividual/entity to access the structure 116 in a malicious manner, theindividual/entity would have to know the address of the structure 116,know the access schedule 136 of a particular guest 110 (e.g., times/daysin which the guest 110 is authorized to access the structure 116), knowthe unique access code 138 of the guest 110, and either steal the guestdevice 112 of the guest 110 or spoof the current location of the guestdevice 112.

FIGS. 5-7 illustrate example processes for facilitating thelocking/unlocking of a structure based on at least one authenticationprotocol. These processes (as well as each process described herein) areillustrated as logical flow graphs, each operation of which represents asequence of operations that can be implemented in hardware, software, ora combination thereof. In the context of software, the operationsrepresent computer-executable instructions stored on one or morecomputer-readable storage media that, when executed by one or moreprocessors, perform the recited operations. Generally,computer-executable instructions include routines, programs, objects,components, data structures, and the like that perform particularfunctions or implement particular abstract data types. The order inwhich the operations are described is not intended to be construed as alimitation, and any number of the described operations can be combinedin any order and/or in parallel to implement the process.

FIG. 5 illustrates a flow diagram of an example process 500 ofgenerating a guest profile and an access code to be used to lock/unlocka smart lock. Moreover, the following actions described with respect toFIG. 5 may be performed by the service provider 102 and/or the contentserver(s) 104, as illustrated with respect to FIGS. 1-4.

Block 502 illustrates receiving, from an owner device of an owner, guestinformation regarding access to a structure by a guest. An owner 106 orprimary user associated with a structure 116 (e.g., a house, aworkplace, a building, etc.) may authorize one or more guests 110 orsecondary users to access the structure 116 when the owner 106/primaryuser is not present. To do so, the owner 106/primary user may send guestinformation 128 to the service provider 102, where the guest information128 may include an identity of the guest 110 (e.g., guest ID 132), atelephone number 134 of the guest 110, and an extent to which the guest110 is authorized to access the structure 116. This may include timesand/or days of the week that the guest 110 is authorized to access thestructure 116, as well as a duration of time in which the guest 110 isauthorized to have access (e.g., 1 week, 1 month, indefinite, etc.).

Block 504 illustrates generating, based on the guest information, aguest profile and an access schedule for the guest. Upon receiving theguest information 128, the service provider 102 may generate a guestprofile 130 for the guest 110, which may be maintained by the contentserver(s) 104 and which may be subsequently used to verify/authenticatethe guest 110 in response to receiving an access request 140 from aguest device 112 of the guest 110. The access schedule 136 may begenerated by the owner 106 and/or the service provider 102 and may besubsequently used to determine if the guest 110 is authorized to accessthe structure 116 at a time at which the access request 140 is receivedfrom the guest 110.

Block 506 illustrates generating an access code for the guest. Theservice provider 102 may also generate a unique access code 138 for theguest 110 and maintain the access code 138 in the guest profile 130. Theaccess code 138 may correspond to a unique dedicated short code that maybe provided by the guest 110 when the guest 110 requests to access orsecure the structure 116.

Block 508 illustrates sending, to a guest device of the guest, theaccess code for subsequent access to the structure. Upon generating theaccess code 138, the service provider 102 may send the access code 138via a text message to the guest device 112 of the guest 110.Alternatively, or in addition, the service provider 102 may send theaccess code 138 associated with the guest 110 to the owner 106 (via atext message, an e-mail message, a mobile application, a website, etc.).The owner 106 may then send the access code 138 to the guest 110 (via atext message, an e-mail message, etc.). The guest 110 may maintain theaccess code 138 for subsequent use.

In certain embodiments, although the access code 138 may be generated bythe service provider 102/content server(s) 104, the access code 138 maybe modifiable by the owner 106 and/or the guest 110. For instance, afterthe service provider 102 sends the access code 138 to the owner 106, theowner 106 may modify the access code 138 (e.g., from “abc123” to“robert”) and then send the modified access code 138 to the guest 110.The owner 106 may also send the modified access code 138 to the serviceprovider 102 so that the service provider 102 may update the guestprofile 130 of the guest 110 to reflect the modified access code 138.Provided that the guest 110 modified the access code 138, the guest 110may inform the service provider 102 and/or the owner 106 of the modifiedaccess code 138. In this scenario, the service provider 102 and/or theowner 106 may have to approve the modification of the access code 138 bythe guest 110.

FIG. 6 illustrates a flow diagram of an example process 600 offacilitating the locking/unlocking of a structure based on a text-basedauthentication protocol. Moreover, the following actions described withrespect to FIG. 6 may be performed by the service provider 102 and/orthe content server(s) 104, as illustrated with respect to FIGS. 1-4.

Block 602 illustrates receiving, from a guest device of a guest and toaccess or secure a structure, a first text message including an accesscode. In order to access or secure a structure 116 (e.g., a house, abuilding, etc.) by causing a structure entrance 118 (e.g., a door) to beunlocked or locked, the guest 110 may submit a text-based access request302. The text-based access request 302 may be a text message sent fromthe guest device 112 to a dedicated short code associated with theservice provider 102, and may include an access code 138 that waspreviously provided to guest 110 by the service provider 102.

In block 604, it is determined whether a telephone number 134 used tosend the text message is verified, which may correspond to the telephonenumber verification 304 illustrated in FIG. 3. That is, the serviceprovider 102 may determine whether the telephone number 134 used to sendthe text message (i.e., the text-based access request 302) matches thetelephone number 134 included in the guest profile 130 of the guest 110.If the telephone numbers 134 do not match (the “no” from block 604),access to the structure 116 will be denied in block 606, and the guestdevice 112 may receive a text message indicating that access to thestructure 116 has been denied.

In block 608, if the telephone number 134 used to send the text messageis verified in block 604 (the “yes” from block 604), it is determinedwhether the access code 138 included in the text message is verified.This may correspond to the access code verification 306 illustrated inFIG. 3. More particularly, the service provider 102 may determinewhether the access code 138 included in the text message matches theaccess code 138 that is included in the guest profile 130 of the guest110 and that was previously provided to the guest device 112 by theservice provider 102. If the access codes 138 do not match (the “no”from block 608), access to the structure 116 will be denied in block606, and the guest device 112 may receive a text message indicating thataccess to the structure 116 has been denied.

In block 610, if the access code 138 included in the text message isverified in block 608 (the “yes” from block 608), it is determinedwhether the guest 110 is authorized to access the structure 116 at thattime. This may correspond to the access schedule verification 308illustrated in FIG. 3. In some embodiments, the service provider 102 mayrefer to the access schedule 136 of the guest 110 to determinetimes/days in which the guest 110 is authorized to access the structure116. If the access schedule 136 indicates that the guest 110 is notauthorized to access the structure 116 at the time at which the guest110 submitted the text-based access request 302 (the “no” from block610), access to the structure 116 will be denied in block 606, and theguest device 112 may receive a text message indicating that access tothe structure 116 has been denied.

However, if the guest 110 is authorized to access the structure 116 atthat time (the “yes” from block 610), block 612 illustrates sending, tothe guest device, a second text message requesting input to lock/unlocka structure entrance at the structure (i.e., the text-based accessinquiry 310). For instance, the service provider 102 may send a textmessage requesting whether the guest 110 would like to lock or unlockthe structure entrance 118 (e.g., text “1” to unlock, text “2” tolock”). In block 614, the service provider 102 may determine whether theguest 110 provides a timely response to the second text message. Forinstance, the service provider 102 may determine whether the guest 110sends a reply text message within a predetermined/threshold amount oftime (e.g., 30 seconds, 1 minute, 5 minutes, etc.). If not (the “no”from block 614), access to the structure 116 will be denied in block606, and the guest device 112 may receive a text message indicating thataccess to the structure 116 has been denied and/or that the text-basedaccess request 302 has timed out. In certain embodiments, thedetermination of whether the reply text message is received within atimely manner may only apply to instances in which the guest 110 isrequesting that the structure entrance 118 be unlocked (e.g., access tothe structure 116).

If the guest 110 responds to the second message in a timely manner (the“yes” from block 614), block 616 illustrates receiving, from the guestdevice, a third text message to lock/unlock the structure entrance. Thethird text message may correspond to the text-based access response 312illustrated in FIG. 3. The third text message may indicate that theguest 110 would like to lock or unlock the structure entrance 118, suchas by the third text messaging including a “1” or a “2.”

Block 618 illustrates sending access instructions to lock/unlock thestructure entrance. In various embodiments, in response to receiving thethird text message, the service provider 102 may send accessinstructions 148 to the lock 120 associated with the structure entrance118. The access instructions 148 may cause the lock 120 to lock orunlock the structure entrance 118, thereby allowing the guest 110 toaccess or secure the structure 116.

Block 620 illustrates sending, to an owner device of an owner associatedwith the structure, an access notification. In some embodiments, theservice provider 102 may inform the owner 106 when a guest 110 accessesor attempts to access the structure 116, as well as instances in whichan unauthorized individual/entity accesses or attempts to access thestructure 116.

FIG. 7 illustrates a flow diagram of an example process 700 offacilitating the locking/unlocking of a structure based on a web-basedauthentication protocol. Moreover, the following actions described withrespect to FIG. 7 may be performed by the service provider 102 and/orthe content server(s) 104, as illustrated with respect to FIGS. 1-4.

Block 702 illustrates receiving, via a website presented on a guestdevice of a guest and to access or secure a structure, an access requestincluding an access code. In order to access or secure a structure 116(e.g., a house, a building, etc.) by causing a structure entrance 118(e.g., a door) to be unlocked or locked, the guest 110 may submit aweb-based access request 402. The web-based access request 402 may besubmitted via a website associated with a link/URL previously providedto the guest device 112 by the service provider 102. The access code 138of the guest 110, as well as the link/URL, may have been previouslyprovided to the guest device 112 via a text message. To submit theweb-based access request 402, the guest 110 may select the link/URL viahis/her guest device 112 and input the access code 138 via the website.

In block 704, it is determined whether the access code 138 included inthe web-based access request 402. This may correspond to the access codeverification 404 illustrated in FIG. 4. More particularly, the serviceprovider 102 may determine whether the access code 138 submitted via thewebsite matches the access code 138 that is included in the guestprofile 130 of the guest 110 and that was previously provided to theguest device 112 by the service provider 102. If the access codes 138 donot match (the “no” from block 704), access to the structure 116 will bedenied in block 706, and the guest device 112 may receive an indicationvia the website that access to the structure 116 has been denied.

In block 708, if the access code 138 included in the web-based accessrequest 402 is verified (the “yes” from block 704), it is determinedwhether the proximity of the guest device is verified, which maycorrespond to the guest device proximity verification 408 illustrated inFIG. 4. In particular, the service provider 102 may determine whetherthe current geographic location of the guest device 112 is within apredetermined or threshold distance (e.g., 5 feet, 10 feet, etc.) from aknown geographic location of the structure 116 or the structure entrance118 that includes the smart lock 120. If the distance between thecurrent location of the guest device 112 and the known location of thestructure 116/structure entrance 118 is greater than the predeterminedor threshold distance (the “no” from block 708), access to the structure116 will be denied in block 706, and the guest device 112 may receive anindication via the website that access to the structure 116 has beendenied.

In block 710, if the guest device 112 is determined to be within thepredetermined/threshold distance from the structure 116/structureentrance 118 (the “yes” from block 708), and the guest device 112 isdetermined to be in proximity to the structure 116, it is determinedwhether the guest 110 is authorized to access the structure 116 at thattime. This may correspond to the access schedule verification 410illustrated in FIG. 4. In some embodiments, the service provider 102 mayrefer to the access schedule 136 of the guest 110 to determinetimes/days in which the guest 110 is authorized to access the structure116. If the access schedule 136 indicates that the guest 110 is notauthorized to access the structure 116 at the time at which the guest110 submitted the web-based access request 402 (the “no” from block710), access to the structure 116 will be denied in block 706, and theguest device 112 may receive an indication via the website that accessto the structure 116 has been denied.

However, if the guest 110 is authorized to access the structure 116 atthat time (the “yes” from block 710), block 712 illustrates requesting,via the website presented on the guest device, input to lock/unlock astructure entrance at the structure (i.e., the web-based access inquiry412). For instance, the service provider 102 may present selectableoptions/buttons via the website that allow the guest 110 to indicate apreference to lock or unlock the structure entrance 118 (e.g., a “lock”button and an “unlock button”). In block 714, the service provider 102may determine whether the guest 110 timely responds to the web-basedaccess inquiry 412 by selecting the “lock” option or the “unlock” optionwithin a predetermined/threshold amount of time (e.g., 30 seconds, 1minute, 5 minutes, etc.). If not (the “no” from block 714), access tothe structure 116 will be denied in block 706, and the guest device 112may receive an indication via the website that access to the structure116 has been denied and/or that the web-based access request 402 hastimed out.

If the guest 110 responds to the web-based access inquiry 412 in atimely manner (the “yes” from block 714), block 716 illustratesreceiving, from the guest device via the website, a request tolock/unlock the structure entrance. The guest 110 selecting the “lock”option or the “unlock” option via the website may correspond to theweb-based access response 414 illustrated in FIG. 4. Such a selectionmay indicate that the guest 110 would like to lock or unlock thestructure entrance 118.

Block 718 illustrates sending access instructions to lock/unlock thestructure entrance. In various embodiments, in response to receiving theweb-based access response 414 via the website, the service provider 102may send access instructions 148 to the lock 120 associated with thestructure entrance 118. The access instructions 148 may cause the lock120 to lock or unlock the structure entrance 118, thereby allowing theguest 110 to access or secure the structure 116.

Block 720 illustrates sending, to an owner device of an owner associatedwith the structure, an access notification. In some embodiments, theservice provider 102 may inform the owner 106 when a guest 110 accessesor attempts to access the structure 116, as well as instances in whichan unauthorized individual/entity accesses or attempts to access thestructure 116.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described. Rather,the specific features and acts are disclosed as exemplary forms ofimplementing the claims.

What is claimed is:
 1. A method comprising: maintaining data associatedwith a first user, the data relating to a structure associated with thefirst user and a structure entrance, having a lock, associated with thestructure; receiving, at a time and via a website associated with a linkor a Uniform Resource Locator (URL), an access request to access thestructure via the structure entrance; determining, based at least partlyon the link or the URL, that the access request is associated with asecond user; determining, based at least partly on the access request,that the second user is authorized to at least one of access or securethe structure at the time; and sending, based at least partly on thesecond user being authorized to at least one of access or secure thestructure at the time, an access instruction to cause the structureentrance to be locked or unlocked.
 2. The method as recited in claim 1,wherein determining that the access request is associated with thesecond user comprises determining that the link or the URL is uniquewith respect to the second user.
 3. The method as recited in claim 1,wherein determining that the access request is associated with thesecond user comprises: determining that the link or the URL was providedto the second user prior to the time; and determining that the accessrequest includes an access code that was provided to the second userprior to the time.
 4. The method as recited in claim 1, whereindetermining that the second user is authorized to at least one of accessor secure the structure at the time comprises: accessing, from the data,an access schedule that identifies at least one of times or days atwhich the second user is authorized to access the structure; anddetermining that the time is included in the at least one of the timesor the days.
 5. The method as recited in claim 1, further comprising:receiving, from a user device of the first user, the data, the dataincluding a telephone number of the second user and access informationindicating an extent to which the second user is authorized to accessthe structure; and generating a user profile for the second user, theuser profile identifying the telephone number of the second user, anaccess schedule that specifies at least one of times or days at whichthe second user is authorized to access the structure, and an accesscode that is sent by the second user with the access request.
 6. Themethod as recited in claim 1, further comprising: presenting, via thewebsite displayed on a user device associated with the second user andbased at least partly on a determination that the second user isauthorized to at least one of access or secure the structure at thetime, a first selectable option to access the structure and a secondselectable option to secure the structure; receiving, via the websitedisplayed on the user device, a selection of the first selectable optionor the second selectable option; and sending, based at least partly onthe selection, the access instruction.
 7. The method as recited in claim1, further comprising sending, to the first user, a notificationassociated with the structure, the notification indicating at least oneof that the second user attempted to access the structure or that thestructure entrance was locked or unlocked.
 8. The method as recited inclaim 1, further comprising: sending, prior to the time and to thesecond user, a first access code; receiving, at the time and via thewebsite associated with the link or the URL, a second access code;determining that the second access code matches the first access code;and determining, based at least partly on the second access codematching the first access code, that the second user is authorized to atleast one of access or secure the structure at the time.
 9. The methodas recited in claim 1, further comprising: receiving, from the firstuser, a request to modify access to the structure by the second user;and updating, based at least partly on the request, the data.
 10. Themethod as recited in claim 1, further comprising: receiving one or moreimages or video that depict the structure entrance at the time, the oneor more images or the video captured by one or more cameras having afield of view that includes the structure entrance; determining that thesecond user is depicted in the one or more images or the video; andsending, based at least partly on the second user being depicted in theone or more images or the video, the access instruction.
 11. A methodcomprising: receiving, at a time and via a website displayed on a userdevice, an access request to access or secure a structure associatedwith a first user via a structure entrance having a lock; presenting,via the website displayed on the user device and based at least partlyon the access request, at least one of a first selectable option toaccess the structure or a second selectable option to secure thestructure; receiving, via the website displayed on the user device, aselection of at least one of the first selectable option or the secondselectable option; and sending, based at least partly on the selection,an access instruction to cause the lock to unlock or lock the structureentrance.
 12. The method as recited in claim 11, further comprisingverifying that a second user associated with the user device isauthorized to access or secure the structure at the time based at leastpartly on an access code provided via the website.
 13. The method asrecited in claim 12, wherein verifying that the second user isauthorized to access or secure the structure comprises: determining thatthe access code was provided to the second user prior to the time; anddetermining that the time corresponds to at least one of times or daysat which the first user authorized the second user to access thestructure via the structure entrance.
 14. The method as recited in claim11, further comprising sending, to the user device, a link or a UniformResource Locator (URL) that is associated with the website and an accesscode, and wherein the access request corresponds to the second userselecting the link or the URL via the user device to cause presentationof the website and inputting the access code via the website.
 15. Themethod as recited in claim 11, further comprising: receiving one or moreimages or video that depict the structure entrance at the time, the oneor more images or the video captured by one or more cameras having afield of view that includes the structure entrance; determining that thesecond user is depicted in the one or more images or the video; andsending, based at least partly on the second user being depicted in theone or more images or the video, the access instruction.
 16. A methodcomprising: maintaining data associated with a first user, the datarelating to a structure associated with the first user and a structureentrance, having a lock, associated with the structure; receiving, at atime, an access request to access the structure via the structureentrance; determining that the access request is associated with asecond user; determining, based at least partly on the access request,that the second user is authorized to at least one of access or securethe structure at the time; receiving one or more images or video thatdepict the structure entrance at the time, the one or more images or thevideo captured by one or more cameras having a field of view thatincludes the structure entrance; determining that the second user isdepicted in the one or more images or the video; and sending, based atleast partly on the second user being depicted in the one or more imagesor the video, an access instruction to cause the structure entrance tobe locked or unlocked.
 17. The method as recited in claim 16, wherein:the access request is received via a website associated with a link or aUniform Resource Locator (URL) that was sent to the second user prior tothe time; the link or the URL is unique with respect to the second user;and determining that the access request is associated with the seconduser is based at least partly on the link or the URL.
 18. The method asrecited in claim 16, wherein the one or more cameras capture the one ormore images or the video upon at least one of detecting motion withinthe field of view or receiving the access request.
 19. The method asrecited in claim 16, further comprising: determining that the one ormore images or the video depict the second user at least one ofattempting to access, accessing, or exiting the structure via thestructure entrance; and providing, to the first user, access to the oneor more images or the video.
 20. The method as recited in claim 16,further comprising: sending, prior to the time and to the second user, afirst access code; receiving, at the time and via a website associatedwith a link or a URL sent to the second user prior to the time, a secondaccess code; determining that the second access code matches the firstaccess code; and determining, based at least partly on the second accesscode matching the first access code, that the second user is authorizedto at least one of access or secure the structure at the time.